I can't consistently reproduce this but I will keep an open for a working test case. Found on m-c 20170728132457 Changeset: 16ffc1d05422a81099ce8b9b59de66dde4c8b2f0 ==10868==AddressSanitizer: while reporting a bug found another one. Ignoring. ==10868==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f3fc14e0e88 at pc 0x7f3fb7a30c91 bp 0x7f3f978cd210 sp 0x7f3f978cd208 ==10868==AddressSanitizer: while reporting a bug found another one. Ignoring. READ of size 8 at 0x7f3fc14e0e88 thread T29 (GLXVsyncThread) #0 0x7f3fb7a30c90 in get src/obj-firefox/dist/include/mozilla/RefPtr.h:284:27 #1 0x7f3fb7a30c90 in operator-> src/obj-firefox/dist/include/mozilla/RefPtr.h:316 #2 0x7f3fb7a30c90 in mozilla::RefreshTimerVsyncDispatcher::NotifyVsync(mozilla::TimeStamp) src/widget/VsyncDispatcher.cpp:117 #3 0x7f3fb38edbcd in mozilla::gfx::VsyncSource::Display::NotifyVsync(mozilla::TimeStamp) src/gfx/thebes/VsyncSource.cpp:68:33 #4 0x7f3fb386ec73 in GLXVsyncSource::GLXDisplay::RunVsync() src/gfx/thebes/gfxPlatformGtk.cpp:787:9 #5 0x7f3fb386f0f2 in applyImpl<GLXVsyncSource::GLXDisplay, void (GLXVsyncSource::GLXDisplay::*)()> src/obj-firefox/dist/include/nsThreadUtils.h:1142:12 #6 0x7f3fb386f0f2 in apply<GLXVsyncSource::GLXDisplay, void (GLXVsyncSource::GLXDisplay::*)()> src/obj-firefox/dist/include/nsThreadUtils.h:1148 #7 0x7f3fb386f0f2 in mozilla::detail::RunnableMethodImpl<GLXVsyncSource::GLXDisplay*, void (GLXVsyncSource::GLXDisplay::*)(), true, (mozilla::RunnableKind)0>::Run() src/obj-firefox/dist/include/nsThreadUtils.h:1192 #8 0x7f3fb2185e53 in RunTask src/ipc/chromium/src/base/message_loop.cc:452:9 #9 0x7f3fb2185e53 in DeferOrRunPendingTask src/ipc/chromium/src/base/message_loop.cc:460 #10 0x7f3fb2185e53 in MessageLoop::DoWork() src/ipc/chromium/src/base/message_loop.cc:535 #11 0x7f3fb2187a79 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) src/ipc/chromium/src/base/message_pump_default.cc:36:31 #12 0x7f3fb2183a2b in RunInternal src/ipc/chromium/src/base/message_loop.cc:326:10 #13 0x7f3fb2183a2b in RunHandler src/ipc/chromium/src/base/message_loop.cc:319 #14 0x7f3fb2183a2b in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:299 #15 0x7f3fb21a1ba9 in base::Thread::ThreadMain() src/ipc/chromium/src/base/thread.cc:181:16 #16 0x7f3fb2191ebc in ThreadFunc(void*) src/ipc/chromium/src/base/platform_thread_posix.cc:38:13 #17 0x7f3fcfa106b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9) #18 0x7f3fcea993dc in clone /build/glibc-bfm8X4/glibc-2.23/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:109 0x7f3fc14e0e88 is located 56 bytes to the left of global variable 'tPath' defined in 'src/xpcom/io/SpecialSystemDirectory.cpp:505:26' (0x7f3fc14e0ec0) of size 8 0x7f3fc14e0e88 is located 0 bytes to the right of global variable 'nsTArrayHeader::sEmptyHdr' defined in 'src/xpcom/ds/nsTArray.cpp:14:32' (0x7f3fc14e0e80) of size 8 SUMMARY: AddressSanitizer: global-buffer-overflow src/obj-firefox/dist/include/mozilla/RefPtr.h:284:27 in get Shadow bytes around the buggy address: 0x0fe878294180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe878294190: 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 0x0fe8782941a0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 0x0fe8782941b0: 00 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 0x0fe8782941c0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 =>0x0fe8782941d0: 00[f9]f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 0x0fe8782941e0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 0x0fe8782941f0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 0x0fe878294200: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 0x0fe878294210: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 0x0fe878294220: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb

There's been a spike in CompositorVsyncDispatcher-related oranges recently too. Not sure if related, but maybe interesting anyway. https://bugzilla.mozilla.org/buglist.cgi?keywords=intermittent-failure&keywords_type=allwords&list_id=13699535&short_desc=CompositorVsyncDispatcher&resolution=---&query_format=advanced&short_desc_type=allwordssubstr

I'd still like a test case. This code hasn't been touched in 2 years and the intermittent looks really rare.

In case it isn't clear, it looks like the code is trying to read from an empty array. I'm not sure how that could happen, unless there's a race. But all accesses to mChildRefreshTimers appear to be guarded by a lock.

We're going to wait until bug 1385372 is fixed and see if that also fixes this (it was found while reducing a testcase).

(In reply to Daniel Veditz [:dveditz] from comment #4) > We're going to wait until bug 1385372 is fixed and see if that also fixes > this (it was found while reducing a testcase). Tyson, is this fixed now?

I am no longer seeing this. I will reopen if it pops back up.